Network analysis includes monitoring different call ends of a conversation and generating performance statistics, including key performance indicators (KPIs), about network performance. Since call failures directly impact end customers and constitute a major factor in customer churn, call failure rate is one of the most important KPIs monitored by a service provider. Considerable amounts of time and money are spent to ensure that call failures are addressed and resolved in a timely fashion.
However, current monitoring solutions monitor different call ends of a conversation separately, treating the different call ends as different respective calls. KPIs, cause codes, and events are reported separately for each of these call ends. As a result, when a call fails, a cause code is attributed to each call end of the call. In a scenario in which each call end of the call is attributed with a failure cause code, both call ends can be penalized, although only one call end was actually at fault. In consequence, performance statistics can be skewed by duplicated attribution of fault for call failures, creating false positives and confusing plans to resolve a cause for the call failure. This can result in an increased mean time to repair (MTTR) that affects customer experience and increases operation costs for the service supplier.
For example, during a conversation between an LTE mobile device A (e.g., voice over LTE (VoLTE)) and a Wi-Fi mobile device B, the Wi-Fi mobile device B may begin to experience poor quality due to increased congestion on its Wi-Fi network. As a result, the call may fail on the Wi-Fi network, such as in conjunction with a real-time transport protocol (RTP) timeout cause code. This call failure may be observed on the LTE mobile device A's LTE network as well, in conjunction with the same RTP Timeout cause code, all while the LTE network maintained a good connection. A network performance engineer may spend a considerable amount of time investigating this call failure on the LTE network, only to find out that the call failure was unrelated to the LTE network, but was due to poor Wi-Fi network connections on the other side of the conversation, which typically is not actionable.
In addition, the poor Wi-Fi connection at Wi-Fi mobile device B can introduce media gaps on the uplink side. However, these media gaps would also be reported for the downlink side of the LTE mobile device A. A network performance engineer may spend a considerable amount of time investigating these media gaps on the LTE network, only to find out that the media gaps were due to poor Wi-Fi network connections on the other side of the conversation, which again is typically not actionable.
Such conventional methods and systems have generally been considered satisfactory for their intended purpose. However, there is still a need in the art for non-duplicated, accurate attribution of fault for call failure and poor network performance.